home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 8144 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.4 KB  |  61 lines
  1. Newsgroups: comp.lang.c
  2. Path: news.sprintlink.net!eskimo!scs
  3. From: scs@eskimo.com (Steve Summit)
  4. Subject: Re: What is &Variable (declared as: char Variable[10])?
  5. X-Nntp-Posting-Host: eskimo.com
  6. Message-ID: <DnLx2r.323@eskimo.com>
  7. Sender: news@eskimo.com (News User Id)
  8. Organization: schmorganization
  9. References: <4gqpa1$3h9@alcor.usc.edu> <4gsdno$1bg@umbc9.umbc.edu> <4gvlnlINNppj@anvil.ugrad.cs.ubc.ca>
  10. Date: Fri, 1 Mar 1996 21:01:38 GMT
  11.  
  12. In article <4gvlnlINNppj@anvil.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca
  13. (Kazimir Kylheku) writes:
  14. > In article <4gsdno$1bg@umbc9.umbc.edu>,
  15. > Jonas J. Schlein <schlein@umbc.edu> wrote:
  16. >> I'm having trouble understanding why it matters? You almost never use the
  17. >> address of an array directly unless doing something tricky with pointers
  18. >> or with particular dimensions of a multiple dimensional array.
  19. > 
  20. > Not necessarily. The address of an array is very useful in
  21. > abstracting away the representation of a variable that happens
  22. > to be represented as an array...  The client can declare a
  23. > variable of [abstract] type... without caring whether it is a
  24. > struct, double, long, array or union.
  25.  
  26. What you say about abstract types is, in general, true, but it's
  27. probably not a good idea to instantiate an abstract type with an
  28. underlying array type, because arrays are second-class citizens
  29. in C.
  30.  
  31. A client programmer might reasonably assume that the sequence
  32.  
  33.     abstract_t x;
  34.     f(x);
  35.  
  36. could not modify x.  In C, this assumption is of course not valid
  37. if abstract_t happens to have array type.
  38.  
  39. As it happens, standard C does contain one abstract type which
  40. is, underneath, an array: jmp_buf, from <setjmp.h>.  Because
  41. setjmp() is traditionally called as
  42.  
  43.     jmp_buf env;
  44.     setjmp(env);
  45.  
  46. and because setjmp() is in fact specified as accepting a
  47. parameter of type jmp_buf, but since setjmp must modify its
  48. argument, we are left with the peculiar requirement that jmp_buf,
  49. though seemingly abstract, must be an array type.
  50.  
  51. If, one day, you find yourself wanting to implement an abstract
  52. type with an array, it's a good idea to wrap the array in a
  53. structure, so that it will be a first-class type.  Otherwise, you
  54. may run into surprises (when your callers find their variables
  55. being unexpectedly modified by calls to your routines) or you may
  56. accidentally lock yourself into maintaining the allegedly
  57. abstract type as an array type (as happened with jmp_buf).
  58.  
  59.                     Steve Summit
  60.                     scs@eskimo.com
  61.